inscatolati - Get out of the box! :)

If you want to change the partition table of a given device on a running system, without rebooting, just go on and modify the partition table, paying attention not to overwrite or shrink any used partition.

Once the partition table has been changed, you need to ask the kernel to reload the partition table and update the devices accordingly. To do so, you can run the command:

# sfdisk -R /dev/sda

where sda is the name of the device where the partition table was changed. If you get the error:

BLKRRPART: Device or resource busy

it means that /dev/sda, or the device you are using, has partitions mounted on it, and the kernel was unable to read the new table. If you want to use the new partition table without rebooting, you need to umount all the old partitions of /dev/sda and then re-run 'sfdisk -R'.

If 'sfdisk -R' returns no error, it means the new partition table was read and that the devices /dev/sda1, /dev/sda2... are now relative to the new partition table you just updated.

• if you run:

  $ cat /proc/partitions

  you get the list of all partitions, as seen by the kernel. This list is usually generated at boot time and updated every time a command issues the BLKRRPART ioctl (sfdisk -R to issue the ioctl manually). This list also includes virtual devices, like those created with the LVM tools and the device-mapper.

  Note that if the partition table was changed, and the system not rebooted, or no BLKRRPART issued or issued with other partitions mounted, /proc/partitions may not reflect the content of the partition tables of the disk. Note also that if the kernel did not detect some partition table or the content of some devices, those partitions might not be available from /proc/partitions.

  Note also that any user can read the content of /proc/partitions, and that all devices in /dev representing partitions will reflect the content of this file.

• you can run:

  # fdisk -l

  or

  # sfdisk -l

  both commands will read the partition table directly from the disk. sfdisk is a very low-level tool, so, the output may slightly differ (sfdisk often shows even unused partitions).

  Note that the above commands can only be run by privileged users. Note also that the output indicates the exact content of the disk, which might not reflect the 'vision' of the kernel. If the partition table was zeroed with a 'dd' without rebooting, or the partition table was changed with a simple fdisk, with 'fdisk -l' you will see the new partition table. However, the devices in /dev, like /dev/sda1 or /dev/hdc2, will refer to the partition table as seen by the kernel, and as readable by the /proc/partitions file.

In kernel 2.4 and first 2.6, raid partitions aka md devices were not partitionable. Even today, most distributions do not support md device partitioning.

There are not many solutions to this problem, either:

• create a single raid device for the whole disk (for example, between /dev/sda and /dev/sdb), create a file system on that single partition, and live with it (mkfs.ext3 /dev/md0, where md0 is made of /dev/sda and /dev/sdb). This should have no problems, beshide that it is not very sane to put a complete system on a single partition...

• create a single raid device for the whole disk (for example, between /dev/sda and /dev/sdb), and use the device mapper (aka lvm) to create logical volumes (aka, partitions). This works, but you cannot boot from a logical volume... neither lilo nor grub support that.

• first create the partitions, and then create the raid devices. For example, you could create a small /dev/sda1 and /dev/sdb1, and a md0 device with the /boot directory on it. Then, create /dev/sda2, /dev/sdb2, /dev/sda3, /dev/sdb3 as needed and raid them separately... this solution works well, but:

  • you have to pay attention when installing the boot loader. Since only partitions are on 'raid', everything out of the partitions, like the MBR (Master boot record) is not in 'raid'. If you simply install grub or lilo as usual, at the first failure, after replacing a disk, you will likely end up with an unbootable system.

  • the solution is not very flexible. If you need to create a new partition, you have to create a new raid device, and so on... if you need to change something, it's hard to do...

  • in case of a disk failure, you will probably end up with many software raid devices not working anymore, and with the kernel having to realize that all or some of them have failed...

• Well, simply create two partitions, /dev/sda1 and /dev/sda2, raid /dev/sda1 with /dev/sdb1, and then use /dev/sda2 in raid with /dev/sdb2 as an phisica volume for LVM. That way, you can boot the system, and create new partitions simply by using the LVM.

With kernel 2.6 and a recent version of mdadm, you can also use the option --auto=mdp to create a partitionable raid volume. One more solution could be to use the EVMS, still not part of the official linux kernel.

If you use LVM over RAID 5 on a 2.4 kernels, you might easily have errors like:

raid5: switching cache buffer size, 4096 --> 1024 raid5: switching cache buffer size, 1024 --> 4096 [...]

These messages are repeated almost everytime there is a disk access, flooding both your console, your logs, and degrading performance.

A quick and easy hack would be to create the filesystem with a block size of 4096. In the case of ext3, something like:

# mkfs.ext2 -b 4096 /dev/mapper/vg00-lv00

With this option, you will see your logs being flooded only when you are using low level tools, like 'vgs', 'lvs', 'tune2fs', and so on...

With other file systems, there are equivalent options to set the block size to 4096 bytes...

As you can read on the Linux Software RAID HOWTO, you should set the type of raid partitions to 0xfd. Note, however, that there are two ways to assemble raid devices:

• asking the kernel to do it automatically, at boot time.

• by running mdadm or the raidhot tools right at boot time, telling them to assemble raid devices.

In practice: if you put 0xfd in the type flag of the partition table, the device will be automatically assembled at boot time. If you don't, you will need to configure mdadm and/or raidhot tools to do that for you (at boot time), or you will have to assemble the device manually.

To create the mdadm configuration file, you have two choices: one, create it manually, two, run

# mdadm --examine --scan > mdadm.conf or # mdadm --detail --scan > mdadm.conf

(the two commands give the same output, sometimes in a different order). These commands require your raid devices to be active and available. If they are not active, you can either assemble them manually, and run the above commands, or use the command:

# mdadm --examine --brief --scan --config=partitions > mdadm.conf

The standard location for the mdadm.conf file, on Debian systems, is /etc/mdadm/mdadm.conf.

Ok, let's say you have a software RAID 1 /dev/md0 device made of two partitions on two different scsi disks, /dev/sda1 and /dev/sdb1.

Let's say you just had a major hardware failure, and for one reason or another, some data was corrupted on the first device, while some other data was corrupted on the second device.

One easy way to try to recover data is to mount /dev/sda1 and /dev/sdb1 individually, recover data, and then, eventually, put them back into the raid.

Doing so, is quite easy:

• if the raid device is still mounted, umount it immediately, with something like 'umount /mount/point/of/raid/device'. You can see the mount point of the md device with something like 'mount |grep md0' or 'cat /proc/mounts |grep md0' (see note mount, read only partitions, and wierd output).

• stop the raid device, with something like:

  # mdadm --misc --stop /dev/md0

  or mark it read only, with:

  # mdadm --misc --readonly /dev/md0

• simply mount the devices independently, using:

  # mount -o ro /dev/sda1 /mnt/sda1 # mount -o ro /dev/sda2 /mnt/sda2

  making sure the /mnt/sda1 and /mnt/sda2 directory exist.

• You can now work on /mnt/sda1 or /mnt/sda2 without problems (...).

• if you later decide that the content of one of the partitions is good, you can start the array in degraded mode with --assemble, or mark /dev/sda2 (for example) as failed, and then simply replace it ...

Ok, so... you are switching from a non-LVM system to using LVM... you have your /dev/sdb, and want to turn it in a Physical Volume to add to a simple Volume Group.

You try with a simple:

# pvcreate /dev/sdb

and you get an error:

Can't open /dev/sdb exclusively. Mounted filesystem?

you check the mount option, with something like:

mount |grep /dev/sdb

and nothing appears... (well, if something appears, just run umount all mounted partitions, and try one more time). So: pvcreate fails, reporting 'Mounted filesystems?', but no file systems are mounted.

The solution is quite simple: as long as the kernel sees partitions on the device, pvcreate will not be able to lock it to create a physical volume... (this is still true on a 2.6.16 with lvm2 2.02.05). So, remove the partitions (with cfdisk/sfdisk/fdisk, whatever you want, or dd if=/dev/zero of=/dev/sdb size=512 count=1) run 'sfdisk -R' and you should be fine... run pvcreate, and you will have no more errors...

# dd if=/dev/zero of=/dev/sdb size=512 count=1 # sfdisk -R # pvcreate /dev/sdb

To backup a partition table, you can simply run:

# sfdisk -d /dev/sda > /home/backup.file

To restore the backup, which means, to repartition the disk as the dump you just generated, you can simply run something like:

# sfdisk /dev/sda < /home/backup.file

Note that the above commands do not save/restore the full MBR: if a boot loader or something similar is installed, its own code will be lost... you may have better luck by using dd, but watchout with extended partitions...

To backup the partition table using dd, simply run:

# dd if=/dev/sda of=/tmp/backup.pt bs=512 count=1

where /dev/sda is the device of which you want to backup the partition table, /tmp/backup.pt is the name of the file where you want your partition to be stored, and bs=512, count=1, tells dd to copy 1 sector of 512 bytes from the beginning of the disk...

This method will backup the full MBR, both the partition table and a small fragment of code used to boot your system in front of the partition table. However, IT WILL NOT BACKUP EXTENDED PARTITIONS!

This means that if you have /dev/sda5, /dev/sda6 or greater... the partition table records about those partitions will be lost. A better solution would be to save both the first sector of the disk using dd, and then the complete backup of the partition table using 'sfdisk -d' (take a look at http://notes.inscatolati.net/system[en]/storage[en]/index.html#29).

So, you have just bought 10/15 bleeding edge scsi disks, of the same type, brand, and of the same kind, and you want to create a partition table on each of them?

A simple way would just be to create a partition table on the first device (sda), with cfdisk, fdisk or whatever you like, and then backup the partition using:

# sfdisk -d /dev/sda > /tmp/backup.pt

Now, for each device, you can simply run:

# sfdisk /dev/sdb < /tmp/backup.pt

In short, something like:

# cfdisk /dev/sda # sfdisk -d /tmp/backup.pt # for dev in /dev/sd{b,c,d,e,f,g,h,i,j,k}; do \ > sfdisk $dev < /tmp/backup.pt; done

should be enough...

Ok, let's say you have created your ext3 root filesystem, and you want to use it with data=journal, instead of the default data=ordered. You cannot umount it, so you try:

mount -o remount,data=journal

Most likely, the command will fail with:

mount: / not mounted already, or bad option

If you also run dmesg, you will see the error:

EXT3-fs: cannot change data mode on remount

so you're stuck. Also, the root partitions gets mounted before fstab is read, so... it's a bit harder to get the options right.

If you cannot reboot the system, the only thing you can try is to play with pivot_root or similar, to try to temporarily move the root on tmpfs / ramdisk / ... but would still need lot of restarting, mount --bind and so on to move the services to the new root.

If you can afford to reboot, and you want data=journal after every reboot, you can use:

tune2fs -o journal_data /dev/sda1

where sda1 is your root partition. Alternatively, on LILO or grub command line, you can pass the option:

rootflags=data=journal

Just:

• check how many extents you have available in the volume group

• use lvcreate with the -l option to specify the number of extents

   % vgs -o vg_name,vg_size,vg_free,vg_extent_count,vg_free_count
   VG     VSize  VFree #Ext  Free
   system 67.96G 8.96G 17397 2293
   % lvcreate -n backup -l 2293 system
   

Instead of using vgs, you can use vgdisplay, and use the field:

[...] Free PE / Size 2293 / 8.96 GB [...]

Just:

• check how many extents you have available in the volume group

• use lvcreate with the -l option to specify the number of extents

   % vgs -o vg_name,vg_size,vg_free,vg_extent_count,vg_free_count
   VG     VSize  VFree #Ext  Free
   system 67.96G 8.96G 17397 2293
   % lvcreate -n backup -l 2293 system
   

Instead of using vgs, you can use vgdisplay, and use the field:

[...] Free PE / Size 2293 / 8.96 GB [...]